Computer users in both the business and home environment have become accustomed to using a computer with a graphical operating system. For example, many users operate computers having a Microsoft Corporation “WINDOWS” operating system thereon. Certain components of these graphical operating systems are known as “controls.” For example, a control may be an “OK” button, which is generally a rectangular button with “OK” written in it. By moving the cursor over the button and clicking on the mouse, a known operation will begin that is associated with the control. Many other controls exist, with examples including scroll bars, dialog boxes and sliders. Beyond controls, the graphical operating systems also draw, or render, other graphical components as needed on the display of the computer, such as the frame, the minimize box and the close box.
There are two general kinds of controls in WINDOWS: standard and custom. Standard controls are provided by the operating system. The code to create, draw and operate standard controls is contained in the common control library (DLL), a part of WINDOWS. Custom controls are all other controls. Custom controls may be created by the manufacturer of the operating system or by third parties. The code for custom controls is contained in a corresponding separate library (DLL) or within an application.
Currently, when a graphical user interface component, such as a control, is used by an application, the application requests that an instance of the component be created. Following this, the operating system transmits a generic message to the component, instructing the component to render itself. The application plays a role in routing the message from the main window to the targeted control, but the control code performs the drawing. The application uses application programming interfaces (API's) to create and interact with the control. An API serves as a software interface to be used by other programs, much as the keypad serves as an interface to a calculator. An API is a fundamental concept of high-level programming. In high-level programming, a program often does not execute tasks by itself. Instead, the program asks some other program to execute these tasks. For example, programs frequently delegate various tasks to the underlying operating system. Continuing with the above example, an application delegates the rendering of a control to the control's code.
In the prior art environment, when a generic rendering message is received by a control to draw itself, the control will draw itself using its own drawing software code. In this prior art environment, the control knows what it is supposed to look like, how it is supposed to behave, and can effectuate such a display on the user interface of the computer. Thus, the application may delegate all aspects of visual rendering to the controls, avoiding the need to contain software code to support the visual rendering of the control within the host application itself.
By utilizing the standard controls defined and rendered by the operating system, all controls will have the same appearance, regardless of the application. Users of graphical operating systems can change only a limited number of characteristics of the controls. In the “WINDOWS” operating system, a user can change the color scheme used to display the various controls and components on the monitor. The user can also select a small set of fonts to be used by the controls and components. The user can also specify a limited number of nonclient sizes that will control the sizing of the nonclient areas. Thus, the colors, fonts and a limited set of sizes of the controls and components may be changed. However, the basic appearance of the controls and components is dictated by the rendering software code within the control library containing the particular graphical component or control. In the prior art environment, to change the appearance of the controls or graphical components, the rendering software code must be altered. For example, if it is desired to change the appearance of the “OK” button, the rendering software code within the operating system DLL file containing the button control must be altered and the DLL file reconstructed at the binary level. If it was desired to render the button as an oval with “okay” written inside, the software code would have to be changed accordingly. Such an approach makes it difficult, if not impossible, for a computer user and for software manufacturers, to easily alter the appearance of the controls and graphical components.
In order to enhance the user experience of the computer, it would be desirable for the user to have the ability to change the overall “look and feel” of the graphical display by changing the overall visual appearance or “theme” of the various graphical components. In other words, it would be desirable if the user could change not only the color and font of the graphical components appearing on the monitor, but to change the appearance of those graphical components as well. For example, it would be desirable to be able to alter and direct the layout of the parts of a control, and to define the shape of a control or its parts. It would also be desirable to control all aspects of how a control or its parts are drawn. Because the controls and graphical components existing within the DLL file in the prior art environment are “hard coded” with their own rendering software code, it is difficult and cumbersome to change the appearance of all of the controls and components. To do so would require recoding each of the controls to achieve the desired appearance. If multiple visual styles were required, they would each have to be predefined and each “hard coded” into every control. Moreover, the controls must also be recoded if a different rendering technology is to be used. For example, if the controls are rendered using a bitmap and it is desired to utilize a vector-based renderer, each control must be altered.
Certain prior art approaches exist that attempt to address the above situation. However, these solutions do not allow all of the controls and graphical components of the entire system to be changed. Instead, the prior art approaches address only limited portions of the set-of displayed components. This allows the appearance of some controls and graphical components to be altered, leaving the remainder unaltered. Such an approach leaves an appearance that is not as coordinated as may be desired.
The prior art approaches are further limited by the techniques they employ to implement control of the appearance characteristics of visual elements of the graphical user interface. Prior art appearance modifiers operate by intercepting the generic rendering signals transmitted to the control, and, using low-level operating system graphical APIs, substitute their own rendering code for that of the control. However, only a portion of the visual elements in the graphical user interface is interceptable. Because the prior art approaches depend exclusively on the interception of operating system signals, not only are they themselves incapable of controlling the appearance of visual elements that do not function according to this protocol, they are incapable of providing a standard means for the author of the visual element to modify the rendering code to accommodate external control.
Further, it is not possible to intercept all relevant signals transmitted by the operating system to a control in the course of rendering. Still further, it is not always possible to reproduce complex visual behavior implemented by a control, such as animated sequences. Thus, the prior art approaches are prone to functional incompatibilities, visual flaws, and performance problems.
Moreover, the prior art techniques do not provide an interface through which software developers can design controls to accommodate versatility in visual appearance. The prior art approaches do not involve an architecture that allows a control author the flexibility to design a control that is “theme aware.” Control authors are therefore not allowed the freedom needed in authoring controls to create controls which can easily be visually altered.
Accordingly, there is a need for an effective system and method for altering the visual style of controls and graphical components that are rendered on the user interface that addresses the above drawbacks and deficiencies. There is also a need for a system and method for altering the visual style of controls and components that are used by an application that can utilize different rendering technologies without requiring modification of the controls and components at the binary level. A need also exists for a system and method for altering the visual style of controls and components that are used by an application that allows a selected theme to be applied to the controls and components without altering the software code of the controls and components. A need also exists for a system that allows software developers and control authors to quickly and efficiently alter the controls and graphical components.